Whats in the change log? ;)

On Tue, Jan 05, 2016 at 01:55:13PM -0800, Vincent Batts wrote:

done in such a way to have a taggable v0.2.0 and then bump to a v0.3.0-dev
This way it's still jive with semver 2.0 section 10

SemVer 2.0 §10 is about build-metadata. The -dev tag you're adding is
a pre-release version (§9). I'd suggest we use PreRelease in the Go
structure to match SemVer, but don't feel particularly strongly about
it. Otherwise, looks good to me.

And I'd like a changelog too 1, but that should land before the tag,
while this bump-to-dev should land after the tag, so that doesn't need
to happen in this PR.

lgtm

@crosbymichael would you rather a ./NEWS or ./ChangeLog file or just a write up in the release tag?

On Wed, Jan 06, 2016 at 07:30:35AM -0800, Vincent Batts wrote:

@crosbymichael would you rather a ./NEWS or ./ChangeLog file or
just a write up in the release tag?

In projects where I'm the only member, I usually use the release-tag
approach. But having a file in the repository that can be updated
incrementally as branches land in master will make future releases
easier.

I've added a ChangeLog. It is automatable, but not concise.

LGTM

On Tue, Jan 12, 2016 at 03:58:50PM -0800, Mrunal Patel wrote:

Merged #294.

I think our release process still needs some polish ;).

$ git log --graph --topo-order --oneline --decorate origin/master

• 837f67d (origin/master, origin/HEAD) Merge pull request Bumpversion v0.3.0 #294 from vbatts/bumpversion_v0.3.0
  |\
  | * bd81312 (vbatts/bumpversion_v0.3.0, origin/pr/294) version: bump v0.3.0-dev
  | * 467fd17 (tag: v0.2.0) version: introduce a string for dev indication
• | 6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
  |\ \
  | * | 408412b (origin/pr/287, policy) style: Collect established styles in a discoverable location
• | | 6a6ba67 (wking/master, master) Merge pull request runtime-config-linux: Add info to clarify oom_score_adj (carrying #236) #292 from vbatts/tiesheng_oomscoreadj
  |\ \ \
  | |_|/
  |/| |
  | * | 011acdf (vbatts/tiesheng_oomscoreadj, origin/pr/292) runtime-config: defer description to linux docs
  | * | 153f13c (origin/pr/236) runtime-config-linux: clarify oom_score_adj
• | | dd17705 Merge pull request Fix typo in Filesystem Bundle #291 from Ephemera/patch-1
  …

So #292 and #287 landed before #294, but aren't actually part of
v0.2.0.

Do we want to land docs about who will update the ChangeLog and when?
Should that come in with the PR (likely to cause trivial merge
conflicts), or be added by the maintainer landing the PR (more work
for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

@wking wacky. I tagged the commit after it hit master. :-\

On Tue, Jan 12, 2016 at 04:27:47PM -0800, Vincent Batts wrote:

@wking wacky. I tagged the commit after it hit master. :-\

git-tag(1) will tag your current commit unless you explicitly specify
in your invocation. So when the branch lands in master
doesn't matter, but what you told git-tag and where your HEAD was
does. Running something like that log command [1](I have it aliased
to ‘glog’ [2]) before publishing the tag will help ensure you've
tagged the commit you meant to tag ;).

my command was git tag -s v0.2.0 467fd17d4f2a987fa00051ce44b69bf9620e2ee6

On Tue, Jan 12, 2016 at 7:36 PM W. Trevor King notifications@github.com
wrote:

On Tue, Jan 12, 2016 at 04:27:47PM -0800, Vincent Batts wrote:

@wking wacky. I tagged the commit after it hit master. :-\

git-tag(1) will tag your current commit unless you explicitly specify
in your invocation. So when the branch lands in master
doesn't matter, but what you told git-tag and where your HEAD was
does. Running something like that log command 1(I have it aliased
to ‘glog’ 2) before publishing the tag will help ensure you've
tagged the commit you meant to tag ;).

—
Reply to this email directly or view it on GitHub
#294 (comment).

On Tue, Jan 12, 2016 at 04:47:11PM -0800, Vincent Batts wrote:

my command was git tag -s v0.2.0 467fd17d4f2a987fa00051ce44b69bf9620e2ee6

Then you got what you wanted, but I would have preferred history like:

• xxxxxxx (origin/master, origin/HEAD) Merge pull request #### from vbatts/post-0.2.0
  |
  | * xxxxxxx version: bump from v0.2.0 to v0.3.0-dev
  |/
• xxxxxxx (tag: v0.2.0) Merge pull request Bumpversion v0.3.0 #294 from vbatts/pre-0.2.0
  |
  | * 467fd17 version: introduce a string for dev indication
• | 6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
  …

Where the v0.2.0 tag contained the ChangeLog (like it does, so good
there) and all master work before the release (it's missing #287 and
#292) but not the v0.3.0-dev bump (which it does not, so good there).

With both the pre-release (ChangeLog) and post-release (v0.3.0-dev)
changes in a single branch, it's hard to do both. You'd have to
rebase onto the tip master, bumping the ChangeLog, etc. just before
merging:

• xxxxxxx (origin/master, origin/HEAD) Merge pull request Bumpversion v0.3.0 #294 from vbatts/bumpversion_v0.3.0
  |
  | * xxxxxxx version: bump from v0.2.0 to v0.3.0-dev
  | * xxxxxxx (tag: v0.2.0) version: introduce a string for dev indication
  |/
• 6aa53ed Merge pull request style: Collect established conventions in a discoverable location #287 from wking/policy
  …

On Tue, Jan 12, 2016 at 04:09:40PM -0800, W. Trevor King wrote:

Do we want to land docs about who will update the ChangeLog and
when? Should that come in with the PR (likely to cause trivial
merge conflicts), or be added by the maintainer landing the PR (more
work for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

As a potential mitigating factor for the trivial merge conflicts of
“ChangeLog entries come with their PR”, I just learned that Gnulib has
a git-merge-changelog driver [1,2,3]. For an example project that
uses this approach, see 4 with PRs like 5.

interesting tooling. we could put a pin in this, but not require action on
it just yet.

On Wed, Jan 27, 2016 at 12:17 AM W. Trevor King notifications@github.com
wrote:

On Tue, Jan 12, 2016 at 04:09:40PM -0800, W. Trevor King wrote:

Do we want to land docs about who will update the ChangeLog and
when? Should that come in with the PR (likely to cause trivial
merge conflicts), or be added by the maintainer landing the PR (more
work for the maintainer), or be added right before cutting a release
(unlikely to lead to a usable ChangeLog)?

As a potential mitigating factor for the trivial merge conflicts of
“ChangeLog entries come with their PR”, I just learned that Gnulib has
a git-merge-changelog driver [1,2,3]. For an example project that
uses this approach, see 4 with PRs like 5.

—
Reply to this email directly or view it on GitHub
#294 (comment).

On Wed, Jan 27, 2016 at 10:14:29AM -0800, Vincent Batts wrote:

interesting tooling. we could put a pin in this, but not require
action on it just yet.

We're curring 0.3.0 soon. Without some sort of plan for updating the
ChangeLog, I think we'll default to “added right before cutting a
release”, which is a fair amount of work to put on the releaser.

I just pushed a minimal image to the docker hub
'vbatts/git-merge-changelog' that I was going to look at playing with

On Wed, Jan 27, 2016, 14:00 W. Trevor King notifications@github.com wrote:

On Wed, Jan 27, 2016 at 10:14:29AM -0800, Vincent Batts wrote:

interesting tooling. we could put a pin in this, but not require
action on it just yet.

We're curring 0.3.0 soon. Without some sort of plan for updating the
ChangeLog, I think we'll default to “added right before cutting a
release”, which is a fair amount of work to put on the releaser.

—
Reply to this email directly or view it on GitHub
#294 (comment).

i'm not sure this is the tool we're looking for. Testing the following. This utility is a helper for merge conflicts around a ChangeLog format file. Not to generate changelogs from merges.

[merge "merge-changelog"]
        name = GNU-style ChangeLog merge driver
        driver = /usr/bin/docker run -it --rm -v $(pwd):$(pwd) -w $(pwd) -u $(id -u) vbatts/git-merge-changelog %O %A %B

On Wed, Jan 27, 2016 at 12:06:41PM -0800, Vincent Batts wrote:

i'm not sure this is the tool we're looking for. Testing the
following. This utility is a helper for merge conflicts around a
ChangeLog format file. Not to generate changelogs from merges.

Right, it's for the “ChangeLog entries come with their PR” workflow
(if that's what we want). If you want to generate entries from
merges, that's the “added right before cutting a release” workflow and
you probably want:

$ git log --first-parent --format='* %s%n%n%b%n' v0.2.0..

and a bunch of hand-editing to separate out breaking changes from
backwards compatible changes, etc.